Communications technologies are at the forefront of rapidly changing requirements of the information age. Only a few short years ago, fax machine technologies threatened the traditional way of receiving information in the mail by electronically encoding content and delivering messages over phone lines. This technology revolutionized the way business had been conducted for hundreds of years. Almost as soon as fax machines became ubiquitous, a new technology known as electronic mail or e-mail began to overtake many applications that were previously and exclusively in the domain of fax machines. As e-mail applications grew, still yet other communications technologies evolved such as Instant Messaging services which again threatened older forms of communications. Along with text driven technologies such as e-mail and fax machines, voice communications have also changed from hard wired connections to the ever popular and growing wireless technologies of today.
In order to manage the wide range of communications options that are available to many users, Unified Messaging (UM) applications have begun to appear that provide a service for handling the many communications options available to users. Unified Messaging generally implies the integration of voice, fax, e-mail, and the like allowing a user to access any of these messages, anywhere, anytime, from any terminal of choice. One goal of a Unified Messaging system is to simplify and speed up communication processes to achieve time and cost savings within a corporation or other entity.
One common feature of modern communications systems is that users are generally given various configuration options from different style menus in order to tailor these systems for particular communications preferences. Thus, voice mail, Unified Messaging and other Intelligent Voice Recognition (IVR) applications have user interfaces that are typically menu driven. A menu consists of one or more prompts that can be played to an end-user on the phone, for example. At the end of the prompt, the user responds with a dual tone multi frequency (DTMF) input that causes the application to change to a different menu. One problem with current technologies is that various application implementations use finite state machines to map these menu changes. Typically these implementations hard code the menu state changes making it difficult to extend and customize the menus.
In one attempt to relieve the burdens of the hard coded nature and control elements for processing messages, technologies such as Voice Extensible Markup Language (VoiceXML) have emerged. A goal of VoiceXML is to bring the full power of Web development and content delivery to voice response applications, and to free the authors of such applications from lower level programming and resource management. It enables integration of voice services with data services using a familiar client-server paradigm. A voice service is viewed as a sequence of interaction dialogs between a user and an implementation platform. The dialogs are provided by document servers, which may be external to a respective implementation platform. Document servers maintain overall service logic, perform database and legacy system operations, and produce dialogs.
A VoiceXML document (or a set of related documents called an application) forms a conversational finite state machine. The user is always in one conversational state, or dialog, at a time. Each dialog determines the next dialog to transition to. Transitions are specified with URIs, which define the next document and dialog to use. If a URI does not refer to a document, the current document is assumed. If it does not refer to a dialog, the first dialog in the document is assumed. Execution is terminated when a dialog does not specify a successor, or if it has an element that explicitly exits the conversation. One problem with how state transitions are processed in VoiceXML relates to the fact that a state change can specify a new document to be retrieved by the document server. Thus, any interaction with a particular user generally requires many transactions with the document server in order to complete a given dialog session. As the number of users grows, the load on respective document servers can become unmanageable. This may cause further resources to be expended such as adding more servers to process the load. Another inefficiency within the documents themselves relate to the amount of scripting code that is required in order to properly transition from one document or dialog to another.